Drop-Down notes in Browser compatibility table use graphic symbols with a meaning *opposite* the intent

[thx1111]

The Browser compatibility table drop-down notes use graphic symbols instead of words to convey meaning. However the meaning conveyed is the opposite of the probable intent. Reading from the table legend, the ⨂︎ style symbol is described as meaning "No support", and the ✓style symbol is described as meaning "Full support". Also, the gray ●︎ style symbol is not listed at all in the legend, and thereby, apparently has no meaning in the drop-down notes.

Consider, as example of the misleading and contrary meaning of a drop-down note, reading from the Browser compatibility table at https://developer.mozilla.org/en-US/docs/Web/CSS/break-before , at the feature "page and avoid-page", for the Opera browser, then selecting the drop-down note, we see:

⨂︎  Opera 11.1 – 12 (Released 2011-04-12)
|
●︎  Removed in 12.1 and later

Based upon the interpretation of the symbols from the table legend, this note says:

"Opera 11.1 – 12 has 'No support' in 11.1 - 12", and then transitions to "[ this feature ] was 'Removed' in versions 12.1 and later",

which means that this feature went from "No support in 11.1 - 12" to a state of "No support in versions 12.1 and later", which is equivalent to saying "This feature has never had support," which renders the drop-down note meaningless.

As I have been told, this note actually is suppose to mean that the browser did have support, and that subsequently, support for the feature was removed. If that interpretation is correct, then the proper drop-down note graphic symbols should be shown instead as:

✓  Opera 11.1 – 12 (Released 2011-04-12)
|
⨂︎  Removed in 12.1 and later

where, again, the gray circle symbol has no meaning, is not included in the legend, and is not needed for any purpose.

See also the discussion at mdn/content#39204

See also the Issue raised at #12776 which addresses accessibility when graphics symbols are used in place of words.

[caugner]

Screenshot showing the status quo:

In this case, it might make more sense to tell the history like this:

• ✅ Added in Opera 11.1 (2011-04-12)
• ❌ Removed in Opera 12.1 (2012-11-20)
• ✅ Added in Opera 37 (2016-05-04)

Unfortunately, this only works well when showing a single linear track.

However, the history can contain multiple concurrent tracks, e.g. if a feature was first supported with an alternative name (or prefix) and later additionally under the regular name.

So we might need to separate these concurrent tracks (e.g. with tabs) to make those cases either to digest.